Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 1/csmp-v1-164.txt

Text File | 1994-12-08 | 42.4 KB | 1,095 lines | [TEXT/R*ch]

C.S.M.P. Digest             Mon, 10 Aug 92       Volume 1 : Issue 164

Today's Topics:

    Is GetTicks accurate on Powerbooks?
    THINK Pascal and MacApp 2.x (was Re: MacApp versus TCL)
    Multiple transmissions using ADSP?! Help!
    Is there anything other than MacinTalk?
    Q: memory err -111 on HandToHand?
    info on innards of Quicktime
    Hide Others...
    Weirdly, Exit Hangs Think Pascal If Debugging Is On
    Palettes vs. Color Tables : need help
    Debugging INITs



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail]
Subject: Is GetTicks accurate on Powerbooks?
Date: 4 Jul 92 18:52:20 GMT
Organization: Queen's University at Kingston


  Do the power-saving or sleep features on a PowerBook prevent the use of
GetTicks for calculating elapsed times?  I need accuracy of the order of a
few seconds over an hour or two.

  Thanks,

.../dave   Dave Charlesworth

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 4 Jul 92 22:53:39 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail]
writes:
>
>Do the power-saving or sleep features on a PowerBook prevent the use of
>GetTicks for calculating elapsed times?  I need accuracy of the order of a
>few seconds over an hour or two.
>

Couldn't you use GetDateTime or ReadDateTime instead? Since you only need to be
accurate to a few seconds, then you shouldn't need the 1/60 second resolution
that ticks give you. And Inside Mac warns you that TickCount (GetTicks is an
Apple IIgs call) can easily skip a tick or two from time to time as interrupts
are disabled, so it's not a good idea to use it for timing over a long period of
time.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.


+++++++++++++++++++++++++++

From: [e-mail]
Date: 5 Jul 92 03:46:43 GMT
Organization: Queen's University at Kingston


  The problem with GetDateTime et al. is that if the user changes the time then
the calculation of elapsed time will be wrong.  GetTicks doesn't have this
drawback.  This application may be used while travelling (suppose I had
money for both a PowerBook AND a return ticket to Cupertino...), or while a
person adjusts their clock (some people use an automated utility to adjust
their clocks daily).

  In summary then, I either need to time things independently of the "time",
or I need to know when the user has adjusted the clock.

  Thanks for your prompt suggestions.

  Cheers,

.../dave   Dave Charlesworth

+++++++++++++++++++++++++++

From: [e-mail] (David Baker)
Date: 6 Jul 92 09:41:24 GMT
Organization: Department of Psychology, Harvard University

In article <[e-mail]> [e-mail] writes:

     Do the power-saving or sleep features on a PowerBook prevent the use of
   GetTicks for calculating elapsed times?  I need accuracy of the order of a
   few seconds over an hour or two.


Dave--

First, I don't think that TickCount is affected by sleep time, but I know it
can be affected by interrupt disabling, as was mentioned in a previous
response.  Why not just avoid the whole problem and use the Time Manager?

David

- --
- -------------------------------------------------------------------------------
David P. Baker                Misbrainer:
Work: [e-mail]        The onions impressed herein are mine,
Home: [e-mail]        not throes of my imploder.
Office: William James Hall, 1204    He wouldn't want 'em, anyway.
    [phone]
    Department of Psychology
    Harvard University
- -------------------------------------------------------------------------------

+++++++++++++++++++++++++++

From: [e-mail]
Date: 7 Jul 92 00:36:07 GMT
Organization: Queen's University at Kingston

David Baker says:

> Why not just avoid the whole problem and use the Time Manager?

Well, you are right I guess.  I've just been following the maxim "use the
simplest tool the will do the job effectively".  Using GetTicks doesn't
require any tasks that need cleanup, doesn't fiddle with A5-worlds at interrupt
time, doesn't have re-entrancy questions, and is less likely to carry the
entire system with it if the application crashes (leaving a pointer for the
Time Manager to execute random memory).  So, it's not that it's difficult,
it's just that I prefer to choose the simpler route if it works.

  None of the things I've seen has definitively said that GetTicks is wrong
on a PowerBook (except for disk accesses and other interrupt-masking, same
as any other Mac).  GetTicks has worked fine for, oh, two or three years now,
but PowerBooks are on the horizon for us (I hope).

  Thanks for your reply.

.../dave  Dave Charlesworth

+++++++++++++++++++++++++++

From: [e-mail] (Steve Dorner)
Date: 7 Jul 92 17:25:25 GMT
Organization: University of Illinois at Urbana-Champaign

<[e-mail]> writes:
> The problem with GetDateTime et al. is that if the user changes the time then
>the calculation of elapsed time will be wrong.
>This application may be used while travelling

Of course, if Apple would ever start keeping the time in UTC instead of
local time, like UNIX has been doing for 20 years, this problem would
be greatly lessened.

For a supposedly "international" computer with "built-in networking" the
Mac is sorely lacking timewise.
- --
Steve Dorner, Official Lame Duck, U of Illinois Computing Services Office
Internet: [e-mail]  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner

+++++++++++++++++++++++++++

From: [e-mail] (Michael Peirce)
Date: 8 Jul 92 00:29:05 GMT
Organization: Peirce Software


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Steve Dorner) writes:
> <[e-mail]> writes:
> > The problem with GetDateTime et al. is that if the user changes the time then
> >the calculation of elapsed time will be wrong.
> >This application may be used while travelling
>
> Of course, if Apple would ever start keeping the time in UTC instead of
> local time, like UNIX has been doing for 20 years, this problem would
> be greatly lessened.
>
> For a supposedly "international" computer with "built-in networking" the
> Mac is sorely lacking timewise.

You can adjust for timezones on the Mac.  Its easy.

The only problem I've run into is that lots of people don't seem to
set their time zone.  Your software can figure this out by noticing
a delta off GMT of zero.  Of course, there are some people who HAVE
a delta off GMT of zero.  My solution to this was to ask once if they
had forgotten to set the timezone or if they really were on GMT.

You set your timezone using the Map control panel.  May people seem
to trash this, so my software provides a way to set the timezone from
within itself too.

- --  Michael Peirce      --   [e-mail]
- --  Peirce Software     --   Suite 301, 719 Hibiscus Place
- --                      --   San Jose, California USA 95117
- --  Makers of...        --   voice: [phone] fax: [phone]
- --            SMOOTHIE  --   AppleLink: peirce & America Online: AFC Peirce

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Wed, 8 Jul 1992 13:10:21 GMT

[e-mail] (Michael Peirce) writes:
>
>The only problem I've run into is that lots of people don't seem to
>set their time zone.  Your software can figure this out by noticing
>a delta off GMT of zero.  Of course, there are some people who HAVE
>a delta off GMT of zero.  My solution to this was to ask once if they
>had forgotten to set the timezone or if they really were on GMT.

I always figured you could check latitude and longitude to see if they
were (0,0)...
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 Life is a merry merry-go-round;  try to learn the secret I have found.
 Free and easy, easy and free.  That's the way it's gotta be.

+++++++++++++++++++++++++++

From: [e-mail] (Steve Dorner)
Date: 8 Jul 92 13:55:52 GMT
Organization: University of Illinois at Urbana-Champaign

[e-mail] (Michael Peirce) writes:
>You can adjust for timezones on the Mac.  Its easy.

And what about the timestamps on files in the filesystem?
It doesn't bother you that by "adjusting for timezones" you can put
your files into the future (or age them prematurely)?

I won't even say "Daylight Savings Time", because it's not supported
(unless somebody can tell me exactly how "dlsDelta" is supposed to
be used, a question I have often asked).

>Of course, there are some people who HAVE
>a delta off GMT of zero.  My solution to this was to ask once if they
>had forgotten to set the timezone or if they really were on GMT.

The Script Manager documentation claims that <0,0,0> means uninitialized.
So you really should only have to do this for people on the equator at
exactly 0 longitude.  This is in the Atlantic Ocean, somewhere near Lagos.
- --
Steve Dorner, Official Lame Duck, U of Illinois Computing Services Office
Internet: [e-mail]  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner

---------------------------

From: [e-mail] (Don Sawtelle)
Subject: THINK Pascal and MacApp 2.x (was Re: MacApp versus TCL)
Date: 8 Jul 92 08:49:57 GMT
Organization: Stonecutter Software

In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Larry Rosenstein) writes:
> Also, you can use MacApp from MPW Object Pascal.  (Or if you have THINK
> Pascal, you may be able to get MacApp 2.x and use MacApp from THINK
> Pascal.)

I have long been a happy advocate of THINK Pascal's fast turnaround
time for MacApp 2.x development. But I have also long suffered the bugs
in Think Pascal that come out of the woodwork when you use it to debug
large MacApp programs. Now I have resigned myself to thinking that
Think Pascal will probably never be solid for MacApp development--
because there aren't many people using MacApp with Think Pascal, and
the number will likely keep dropping given the success of the C++
emphasis of MacApp 3. For that matter, I'm not sure why Symantec would
put the effort into another major rev of Think Pascal, except as part
of maintaining a presence whatever education markets may still be doing
a lot of Pascal.

Therefore I caution those who haven't already made the investment in
figuring out how to live with the problems: avoid using Think Pascal
for MacApp development.

For example:

Reset is dangerous. If a bug makes it impossible for me to Quit from the
application being debugged I reboot rather than Reset. Otherwise Think
Pascal crashes later. (sooner? :-)

You can't use the Think debugger to debug failure handling during
application initialization. If you do, Think Pascal crashes. In order
to do any debugging of failure handling during application
initialization, you have to (for example) split your custom application
initialization off from MacApp's built-in application initialization
and use a flag to trigger yours during the first cycle of the event loop.

Some have reported incompatibility between 4.0.1 and the special
versions of Failure that make it possible to use the THINK Pascal
debugger after a failure has occurred. In some cases, this may be
specific to the Quadra. I don't know; I decided to stick with 4.0.

Projects sometimes get corrupted. They can't be fixed by removing
objects and recompiling everything--you have to create a new project
from scratch. Corrupted projects can cause weird symptoms that look
like bugs in your application, causing major false bug-hunt sidetracks
that eat gobs of time before you finally find that rebuilding the
project from scratch makes everything work just perfectly.

Some of these problems might be fixed in 4.0.1, I don't know. My
attempt to use 4.0.1 on a large MacApp application failed miserably--I
experienced repeated not-enough-memory errors (when there was enough)
and crashes during compiles, without ever having run the
application--which is why I went running back to 4.0.

Other than these serious problems Think Pascal is a great environment
for MacApp development. I live with the problems in order to avoid
the slow turnaround of MPW and because I like the Think Pascal
debugger. I'm still using MacApp 2 because I've been working on a
mature, stable application that I wrote before MacApp 3 existed. I
wouldn't start a new project in MacApp 2.

In general I like the Think compilers, but I find that Think Pascal has
repeatedly fallen short of the mark for MacApp development. And at this point
the economics probably don't justify trying to fix the problem, given the
decline of MacApp 2 and Object Pascal.

Don

- ---
Don Sawtelle:Stonecutter Software:Mariposa, CA
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Rich Siegel)
Organization: GCC Technologies
Date: Wed, 8 Jul 1992 12:08:35 GMT

In article <[e-mail]> [e-mail] writes:
>
>I have long been a happy advocate of THINK Pascal's fast turnaround
>time for MacApp 2.x development. But I have also long suffered the bugs
>in Think Pascal that come out of the woodwork when you use it to debug
>large MacApp programs. Now I have resigned myself to thinking that
>Think Pascal will probably never be solid for MacApp development--

[enumerates problems using MacApp with THINK Pascal]

In general, the instabilities encountered when using MacApp in THINK
Pascal are traceable back to one simple problem: MacApp was never
intended for use with anything other than MPW.

MacApp 2.0 made use of new language constructs which were (at the
time) supported only by the MPW Pascal compiler; it was clear that
many of these extensions were added purely to support MacApp, and for
no other reason.

At runtime, the MacApp architecture made lots of assumptions about the
environment it was running in; initially, MacApp assumed that (a) it
owned the window list; (b) its code resources and all other
application resources were in the same resource file, and (c) a number
of other little things which are only true when running as a
standalone application. MacApp plays all kinds of little games with
the machine which should only be played by one at a time, such as
installing exception vector hooks, bottlenecking some of the same
traps that THINK Pascal itself bottlenecks, and so forth.

The bottom line is that MacApp and THINK Pascal are not an entirely
happy mixture. Don's experiences are pretty rare - many MacApp users
don't seem to have problems (or if they do, they don't report them) -
but they're not unique either. The turnaround time is superior, and
things generally work well, but when push comes to shove, things
break.

The original MacApp conversion for THINK Pascal was done under heavy
marketing pressure, applied by a vocal minority. It was started when
there was no clear idea of the scope of effort involved, took longer
than expected to complete, required a whole lot of blood, sweat,
tears, and cursing on the part of the THINK Pascal 3.0 team (including
myself, who handled compatibility from the MacApp end), and has added
no significant value to the product. (A couple of useful features have
gone into the linker, but that's about it...) The investment of time
and money has not been returned, as far as I am aware. When Apple
announced the decision to switch to C++ for MacApp, I was both bitter
and relieved; bitter, because we'd gone to all this work only to have
the rug jerked out, and relieved because I wasn't going to have to
wrestle with the damn thing anymore.

So, having vented thus far, let me repeat the following: If you want
to use MacApp and Pascal, use MPW. It's way slow, and the debuggers
aren't very good compared to THINK Pascal, but MacApp is happiest that
way.  For any other Pascal task, get THINK Pascal. If you don't have a
class library and want one, start with THINK Pascal (or THINK C) and
the THINK Class Library. It's the easiest way to get started, and what
you learn with the TCL can be applied to learning MacApp, should you
ever choose to do so.

R.
- --
- -----------------------------------------------------------------------
Rich Siegel                              Internet: [e-mail]
Software Engineer & Toolsmith
GCC Technologies

---------------------------

From: [e-mail] (Jerome Chan)
Subject: Multiple transmissions using ADSP?! Help!
Date: 1 Jul 92 02:50:58 GMT
Organization: Alethea, The Twilight World!


  I'm trying to write a small little Net Trek / Dog Fight game and I ran
across this question:

  Is it possible to "broadcast/multi-cast" to using ADSP connections?

  I'm thinking of having a "client" that displays a map showing all the
enemy ships and a "server" that does all the necessary calculations. I
was wondering if I could transmit the location of all the ships at one
time instead of using brute force and transmitting the same positional
data to each "Client" separately.

  I know you can have several CCBs to a socket (it's documented in Vol
VI)  but is it possible to have several "Clients" talking or listening to
ONE socket on the "server"? If this is possible, how will the "server"
know which "client" is sending the data?

  Just an uncertain Mac Programmer.

* Alert New Virus T4 discovered! Check comp.sys.mac.announce! *

- ---
 Fading

+++++++++++++++++++++++++++

From: Jerome Chan <[e-mail]>
Organization: Alethea, The Twilight World!
Date: Wed, 1 Jul 92 06:08:33 GMT

In article <[e-mail]> Jerome Chan,
[e-mail] writes:
>  Is it possible to "broadcast/multi-cast" to using ADSP connections?

If I can't use ADSP, what other protocols can I use for a broadcast type
call? Is there documentation somewhere to help me on this?

+++++++++++++++++++++++++++

From: [e-mail] (Juri Munkki)
Date: 1 Jul 92 22:32:50 GMT
Organization: Helsinki University of Technology

In article <[e-mail]> Jerome Chan <[e-mail]> writes:
>Is it possible to "broadcast/multi-cast" to using ADSP connections?

Not as far as I know.

>If I can't use ADSP, what other protocols can I use for a broadcast type
>call? Is there documentation somewhere to help me on this?

DDP is the highest Appletalk protocol level that supports broadcasting.
The problem is that all the receiving stations must use the same socket
number, so you can't rely on dynamic socket number allocation and that
means that you either have to reserve your own socket number or try to
pick one of the experimental socket numbers and hope that no one else
is using that number.

Further problems:

    o   DDP broadcasts only reach one physical zone.
    o   DDP only makes a best effort to send a packet.
        It never resends or checks for lost packets.
    o   DDP packet size is limited.
    o   You have to write a socket listener is assembly language.

If you are good at writing network software, DDP is probably the
most efficient way to write a multiple player network protocol. The
problems might still outweigh the benefits.

If you can write your game without broadcasts using a higher level
protocol, do it. Appletalk isn't really designed for broadcasts.

If only we had more intelligent and faster hardware network support,
there would be no need to use tricks to make communications to multiple
clients fast. (Ethertalk is fast enough. Localtalk is slow and processor-
intensive.)

- --
  Juri Munkki                           Windsurf: fast sailing
 [e-mail]                          Macintosh: fast software

+++++++++++++++++++++++++++

From: [e-mail] (Jerome Chan)
Date: 2 Jul 92 02:44:40 GMT
Organization: Alethea, The Twilight World!

In article <[e-mail]> Juri Munkki,
[e-mail] writes:
>Further problems:
>
>    o   DDP broadcasts only reach one physical zone.
>    o   DDP only makes a best effort to send a packet.
>        It never resends or checks for lost packets.
>    o   DDP packet size is limited.
>    o   You have to write a socket listener is assembly language.

  I've arrived at the same conclusion after some hours ripping through
Inside Macintoshes, the Q & A stack (4.0.9) and very helpful mail from
several Net Persons. Thanks People!

  The Q & A stack also says that broadcasting data tends to slow down
other Macintoshes on the network, so broadcasting is out of the question
(Besides my network manager would kill me! :)). I'll most probably have a
little loop that resends the same data over and over again.

  I'm not too worried about lost packets as the data is very time
critical and missing a few packets won't affect the game much (I hope
:)) and the size of the data packets aren't that big.

  What's wrong with the default DDP socket listener provided by Apple? Is
there a problem with it? Why do I have to write my own socket listener?

  Thanks also to Stuart Cheshire <[e-mail]> for sharing
his DDP loop idea where each macintosh relays each packet from one
machine to another in a circle. Thanks also to [e-mail] (Jim
Cathey), "Mike Shoemaker" <[e-mail]>,
[e-mail] (Dave Milton) and Peter N Lewis
<[e-mail]> for their advice.

  Apple, please defragement your documentation as fast as possible.
Searching through Tech Notes, Hypercard Stacks and Inside Macintosh is
not fun. Please, please, pretty please. :)

- ---
 Fading

+++++++++++++++++++++++++++

From: [e-mail] (Juri Munkki)
Organization: Helsinki University of Technology
Date: Thu, 2 Jul 1992 16:32:20 GMT

In article <[e-mail]> Jerome Chan <[e-mail]> writes:
>  What's wrong with the default DDP socket listener provided by Apple? Is
>there a problem with it? Why do I have to write my own socket listener?

I think it had problems with MultiFinder, but I'm not sure. Anyway, I think
it exists only in the old Pascal-style interfaces. Correct me if I'm wrong.

Before you go off and write your own stuff, you should probably check out
the ADSP and NBP classes that were posted at ftp.brown.edu just a few days
ago. I'll certainly try them if I need to do some network programming.
Objects should make networking much easier than it is now and I have heard
only good things about ADSP.

- --
  Juri Munkki                           Windsurf: fast sailing
 [e-mail]                          Macintosh: fast software

---------------------------

From: [e-mail] (Hyo E. Ahn)
Subject: Is there anything other than MacinTalk?
Organization: Los Alamos National Laboratory
Date: Wed, 1 Jul 1992 10:02:00 GMT


    Is there anything other than Macintalk to generate human voice?
    I am curious to know if it's possible to have some color in generating
    human voice (e.g., child voice).


    Hyo Ahn, Los Alamos National Laboratory

    Bitnet:        AHN@LAMPF
    Internet:    [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Carl W. Haynes III)
Date: 1 Jul 92 18:46:26 GMT
Organization: Purdue University

In article <[e-mail]> [e-mail] (Hyo E. Ahn) writes:
>
>    Is there anything other than Macintalk to generate human voice?
>    I am curious to know if it's possible to have some color in generating
>    human voice (e.g., child voice).

On page 92 of the July issue of Byte there is a little blurb about the
Sound Bytes Developer's Kit which is described as letting you
incorporate speech Synthessis into new or existing Mac applications.
This is all I know about it, I called and they're supposed to send me
info about it. Contact is listed as:

  Emerson & Stern Associates
  10150 Sorento Valley Rd.
  Suite 210
  San Diego, CA 92121
  voice: 619-457-2526
  fax: [phone]

Price is listed at $3750.00 plus run-time license fees, obviously aimed
at commercial developers.
I'd be happy to post more info when I get the literature, if there's interest.

Then again, there's always Apple's new text-to-speech synthesiser they've
been talking about for years. Although they have given no hint of
a release date.

carl


- --
Carl W. Haynes III
Haynes Consulting Services        ||  [e-mail]
PO Box 2715                       ||  [e-mail]
W. Lafayette, IN 47906            ||  voice: 317 463-6383
- ----------------------------------------------------------------------
                  Macintosh Programming & Consulting

---------------------------

From: [e-mail] (Ramon M. Felciano)
Subject: Q: memory err -111 on HandToHand?
Date: 1 Jul 92 22:56:27 GMT
Organization: DSO, Stanford University

I'm trying to make a copy of a handle grabbed from my TE record.

I pull it out of the record, then do a HandToHand on it. I get -111 as
a result (memWZerr), which THINK Reference says means I tried to
operate on a "free" block. What does that mean?

Thanks!

Ramon

+++++++++++++++++++++++++++

From: [e-mail] (Neal Trautman)
Date: 2 Jul 92 12:39:38 GMT
Organization: Farallon Computing, Inc.

In article <[e-mail]>, [e-mail] (Ramon M. Felciano) writes:
>
> I'm trying to make a copy of a handle grabbed from my TE record.
>
> I pull it out of the record, then do a HandToHand on it. I get -111 as
> a result (memWZerr), which THINK Reference says means I tried to
> operate on a "free" block. What does that mean?
>

I ran into this just yesterday.  It turned out in my
case that some "other" software was building the handle
by having a global handle variable that pointed to a
global pointer variable that pointed to 10 bytes of global
data that contained region data.  In which case the
handle's data was not in a valid heap zone.  I think
the way I am going to fix it is to call NewHandle
and BlockMove instead of HandToHand.  Since the data
is a region, I'll just use the rgnSize field.

- --
Neal Trautman
Timbuktu Lead Software Engineer
Farallon Computing, Inc.
[e-mail]


+++++++++++++++++++++++++++

From: [e-mail] (John Gibson)
Organization: Princeton University
Date: Thu, 2 Jul 1992 14:33:35 GMT

In article <[e-mail]> [e-mail] (Neal Trautman) writes:
>In article <[e-mail]>, [e-mail] (Ramon M. Felciano) writes:
>>
>> I'm trying to make a copy of a handle grabbed from my TE record.
>>
>> I pull it out of the record, then do a HandToHand on it. I get -111 as
>> a result (memWZerr), which THINK Reference says means I tried to
>> operate on a "free" block. What does that mean?
>>
>
>I ran into this just yesterday.  It turned out in my
>case that some "other" software was building the handle
>by having a global handle variable that pointed to a
>global pointer variable that pointed to 10 bytes of global
>data that contained region data.  In which case the
>handle's data was not in a valid heap zone.  I think

Remember also that HandToHand takes a pointer to a Handle,
not a Handle. From MacProtos.h:

pascal OSErr HandToHand(Handle *h);

I vaguely remember getting that error when I passed a Handle
instead.

So it should be

Handle aValidHandle;

result = HandToHand(&aValidHandle);

- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
John Gibson                          Princeton Univ. Dept. of Music
[e-mail]

---------------------------

From: [e-mail] (babb j)
Subject: info on innards of Quicktime
Date: 6 Jul 92 17:57:05 GMT
Organization: San Diego State University Computing Services


I'm looking for a couple of definitve articles about QuickTime. What I'd
like to know about are: the algorithms used, the format(s) of mooV-ies,
are as many frames loaded into available memory as possible or is the
working space for a movie a set size and region?, etc. If you know of any
please lemme know.
Thanx, Jeff.

- --
Jeff Babb - Programmer/Technical Support - San Diego State University
Language Acquisition Resource Center (L.A.R.C.) [phone]
[e-mail]
.."now go away or I shall taunt you a second time" M.P.& T.H.G.

+++++++++++++++++++++++++++

From: [e-mail] (Ivan M CaveroBelaunde)
Date: 7 Jul 92 14:51:09 GMT
Organization: The World Public Access UNIX, Brookline, MA

[e-mail] (babb j) writes:


>I'm looking for a couple of definitve articles about QuickTime. What I'd
>like to know about are: the algorithms used, the format(s) of mooV-ies,
>are as many frames loaded into available memory as possible or is the
>working space for a movie a set size and region?, etc. If you know of any
>please lemme know.
>Thanx, Jeff.

The algorithms used will vary; part of QuickTime is a plug-in architectural
construct (the Component Manager) that allows you to use any algorithm
at all. The built in ones are three (really four, but the fourth one is a
"mock" algorithm that does no compression at all, just bit depth conversion
with or without error diffusion):
    1. Animation Compressor: Uses an optionally lossy run-length coder
        for compressing the images at various bit depths. It can
        only be lossy in non-indexed bit depths (ie 16/24/32 bpp).
    2. Photo Compressor: Uses the ISO JPEG algorithm to compress 24 bpp
        images. High quality, compact compression, trades off with
        lack o' speed. Also gets nasty artifacts on sharp edges.
    3. Video Compressor: Proprietary optionally lossy algorithm developed
        by Apple. Designed to decompress at reasonable speeds to
        permit video playback. Implementation details of the
        algorithm are not readily available, but it is licensable
        (and a number of people have signed up, I believe).

The format of movies: it depends on what you mean. There are two formats
for movies: a public movie format, which is used to save and load movies
to/from disk, which is too complex to describe in detail here but which is
extensively described in the QuickTime documentation. The private movie
format is what the movie looks like when it's in memory: for all intents
and purposes, the Movie data type is an abstract container. The contents
are undocumented, and only accessible programatically. Peeking in them is
very much a no-no, since it's way likely that they'll change. Both the
private and public movie formats, however, do not contain any playable
media data at all. Rather, they are a complex set of "pointers," if you
will, into one or more data files that contain the data that describes the
media (sampled sound data, compressed image data, etc.).

Finally, movies have a "format" in a sense of the sampled digital data that
the media actually consists of. This "format" is really determined by the
"pointers" in the Movie format described above, where the data file is
effectively a sequence of digitized samples, and the "pointers" provide
information about the location and size of the samples in the data stream,
as well as information about the nature of the samples themselves (if it's
a compressed image, what compressor was used for it; if sound data, stuff
like sampling rate, etc.). The format of the samples themselves will vary
with the type of the sample. Some, such as chunks of digitized uncompressed
sound, or images compressed with standard algorithms like JPEG, will be
straightforward to extract and "parse." Others, such as compressed images
in proprietary algorithms such as Apple's Video Compressor (Road Pizza),
are nigh impossible unless you license the stuff from Apple.

Memory usage: It depends; the programmer can ask QuickTime to load
specific parts of a Movie into RAM (LoadMovieIntoRAM/LoadMediaIntoRAM calls)
for faster playback. In the course of normal playback, QuickTime will fetch
the data from disk as requested by the movie's clock. QuickTime will also
attempt to cache part of it (each track has a 64K cache associated with it)
for faster retrieval.

I'm not sure what you mean by "is the working space for a movie a set size
or region." If you're talking about memory, QuickTime will scavenge memory
from all kindsa places, and if it can't get what it needs, it will not play
that frame/frames that are being troublesome.  Spatially, you can make the
"working space" any size or any region (by using clipping), but the bigger
your movie is the more stress it places on machine resources and thus
it'll be more likely to fail to play properly on lower end machines, or
on CD-ROMs, or, if you make it big enough, it might not even play on a
Quadra... ;)

Hope this helps,

- -Ivanski

- ---
Ivan Cavero Belaunde
Visualist
DiVA Corporation

        "A tu escuela llegue, sin entender por que llegaba,
         En tus salones encuentro, mil caminos y encrucijadas,
         Y aprendo mucho ... Y no aprendo na'a ...
         !Maestra vida, camara', te da, te quita, te quita y te da..."
                - Ruben Blades, "Maestra Vida"

---------------------------

From: [e-mail] (JASON HOLTZAPPLE)
Subject: Hide Others...
Date: 1 Jul 92 02:17:51 GMT
Organization: Duke University; Durham, N.C.


  I'm posting this on behalf of a friend who does not have access to
this newsgroup, but his question has me baffled too:
  Is there a way to send a "Hide Others" command from within an
application? I'm assuming you would have to get the handle to the
application menu and then simulate a mouse down on that selection.
I can't find anything in IM to help. What's the best way to go about
this?
Thanks in advance,
Jason Holtzapple
- --
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Ivan M CaveroBelaunde)
Date: 7 Jul 92 14:12:21 GMT
Organization: The World Public Access UNIX, Brookline, MA

It's not quite legal to do so (you have to rely on undocumented info) but
it's possible. Basically, you need to peek into the menu list with
Macsbug to find out the menu ID of the application menu and then use
the SystemMenu trap to execute it.

Be forewarned that the menu ID of the app menu is not officially documented
and you'll probably need to rev your software in the future. You might want
to do some sanity checks to see if it's possible the ID you have in your
code is not valid (get the menu handle and do some sanity checks on that,
or check the system version before doing it and only do it if it's on a
system that you KNOW has that ID for the app menu, etc).

Hope this helps,

- -Ivan

Ivan Cavero Belaunde ([e-mail])
Visualist
DiVA Corporation

    "A tu escuela llegue, sin entender por que llegaba,
     En tus salones encuentro, mil caminos y encrucijadas,
     Y aprendo mucho ... Y no aprendo na'a ...
     !Maestra vida, camara', te da, te quita, te quita y te da..."
        - Ruben Blades, "Maestra Vida"

---------------------------

From: [e-mail] (P. Hawthorne)
Subject: Weirdly, Exit Hangs Think Pascal If Debugging Is On
Date: 7 Jul 92 11:02:53 GMT
Organization: Reed College, Portland OR

The following program hangs Think Pascal if and only if debugging is on.
Why? I've reinstalled the Think Pascal 4.0.1 application, created new
projects, done everything else I can think of, and it still does it.
It didn't used to, as I recall.

program Something;
 procedure Test;
  procedure Check (aCondition: Boolean);

  begin
   if not aCondition then
    Exit(Test);
  end;

 begin
  Check(false);
 end;

begin
 Test;
end.

All of the segments are locked, neither code optimizations nor compiler
directives nor runtime libraries make any difference.

This has me stumped. As you have probably guessed, the program above is
the result of a long and particularly frustrating bug hunt.

Once upon a time, I found that I could not perform the equivalent of a
longjmp out of static links in Think Pascal, and never quite figured
out why not. Oh man, you wanna talk about wacky...

Theus ([e-mail])

+++++++++++++++++++++++++++

From: [e-mail] (Rich Siegel)
Date: 7 Jul 92 12:01:37 GMT
Organization: GCC Technologies

In article <[e-mail]> [e-mail] (P. Hawthorne) writes:
    [ hangs when doing an uplevel exit() from a nested function ]

A bug, which, as far as I know, will be fixed in the next patch of THINK
Pascal. In the meantime, you can either live with it or go back to 4.0,
which shouldn't have this problem.

R.



- --
- -----------------------------------------------------------------------
Rich Siegel                              Internet: [e-mail]
Software Engineer & Toolsmith
GCC Technologies

---------------------------

From: [e-mail]!nextweek.Reed.Edu!pcalahan (Patrick John Calahan)
Subject: Palettes vs. Color Tables : need help
Date: 7 Jul 92 17:14:29 GMT
Organization: Reed College, Portland, OR

I am writing a game and am trying to figure out how to deal with color.
Animation in the game is through copybits-ing pixmaps, and i would like to
do additional color animation by animating the palette or color table.

My question is, should I even deal with palettes, or should i animate the
color table directly?  Since speed is of the essence, I don't want
copybits to be slowed down with any color translation...or maybe this
isn't a problem?

I'm only beginning to dig into color quickdraw, so any advice on
whether/how I should deal with the Palette Manager would be appreciated.

Thanks

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Tue, 7 Jul 1992 18:43:26 GMT

[e-mail]!nextweek.Reed.Edu!pcalahan (Patrick John Calahan) writes:
>I am writing a game and am trying to figure out how to deal with color.
>Animation in the game is through copybits-ing pixmaps, and i would like to
>do additional color animation by animating the palette or color table.
>
>My question is, should I even deal with palettes, or should i animate the
>color table directly?  Since speed is of the essence, I don't want
>copybits to be slowed down with any color translation...or maybe this
>isn't a problem?

It's not a problem if you do it right.  What you want to do is use the
Palette Manager to get to a screen's color table as directly as
possible, thereby garnering for yourself all the benefits of the P.M.
(compatibility, not having to worry about restoring colors) without the
side-effects of the C.M. (incompatibility, having to worry about
restoring colors).

N.B.:  You gotta give up the first and the last color in the CLUT to do
this, since the P.M. won't ever touch those.  If that's not OK, take a
deep breath and prepare to sink yourself into the Color Manager...

What you want to do is tell CopyBits that your source pixmap will be
using the exact same color table as your destination pixmap, so that
CopyBits will say, "oh, ok, well I guess I don't need to look at what
I'm copying then, I'll just do it as fast as possible."  And it helps if
that's _true_, i.e. if you don't have to lie to CopyBits in order to get
the speed.

One of the ways to do this, and probably the easiest, is to set your
offscreen (source) pixmap's pmTable field to be equal to your GDevice's
pixmap's pmTable field.  Since that field is a handle, your offscreen
pixmap's color table will then and thenceforth be exactly equal to
your onscreen pixmap's.

(Another way, which is probably harder, is to set the offscreen's
(**pmTable).ctSeed equal to the onscreen's (**pmTable).ctSeed.  But
then, unless you update your offscreen pmTable every time you change
your onscreen pmTable, you'll be lying to CopyBits, and you may
experience nasty-looking colors if you ever try to open a port and draw
into the pixmap.)

Once you've done that, open up a window on that GDevice and attach a
palette to it.  Set the usage of every color that's important to you to
pmAnimated+pmExplicit.  Then, when you need to set colors, change the
colors' values and call AnimatePalette().  The pmAnimated usage will
mean that the colors won't be used by any other windows, and the
pmExplicit usage will mean that palette entry n will correspond to CLUT
entry n.

How's that sound?
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 If I see one more goddam signature virus, I'm gonna scream.

---------------------------

From: [e-mail] (Lester Ward)
Subject: Debugging INITs
Date: 7 Jul 92 18:02:49 GMT

This has probably been beat to death here, but I didn't see it in the FAQ
sheets.  What is the best way to debug INITs using MPW?

Please mail,
I'll summerize,
Thanks,
Les

+++++++++++++++++++++++++++

From: [e-mail] (Michael Peirce)
Date: 7 Jul 92 23:34:08 GMT
Organization: Peirce Software


In article <ward1.710532169@husc8> (comp.sys.mac.programmer), [e-mail] (Lester Ward) writes:
> This has probably been beat to death here, but I didn't see it in the FAQ
> sheets.  What is the best way to debug INITs using MPW?

Jasik's The Debugger can be setup to debug INITs so you can step through
your INIT at the source level.

An alternative is to sprinkle lots of DebugStr's throughout your code
and do a lot of rebooting (hey, this works :-) with MacsBug installed.

- --  Michael Peirce      --   [e-mail]
- --  Peirce Software     --   Suite 301, 719 Hibiscus Place
- --                      --   San Jose, California USA 95117
- --  Makers of...        --   voice: [phone] fax: [phone]
- --            SMOOTHIE  --   AppleLink: peirce & America Online: AFC Peirce

---------------------------

End of C.S.M.P. Digest
**********************